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I. REAL PARTY IN INTEREST 

The real party in interest in the present application is the following party: Sprint 
Communications Company, L.P. 

II. RELATED APPEALS AND INTERFERENCES 

None. 

III. STATUS OF CLAIMS 

A. Total Number of Claims in the Application 

The claims in the application are: 1-12 

B. Status of All Claims in the Application 

1 . Claims canceled: None 

2. Claims withdrawn from consideration but not canceled: None 

3. Claims pending: 1-12 

4. Claims allowed: None 

5. Claims rejected: 1-12 

C. Claims on Appeal 

The claims on appeal are: 1-12 

IV. STATUS OF AMENDMENTS 

Claim 1 was amended to correct a typographical error in the Response to Final Office 
Action dated August 3 1 , 2007. The Advisory Action dated September 20, 2007 indicated that 
for the purposes of appeal, the proposed amendment will be entered. 
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V. SUMMARY OF CLAIMED SUBJECT MATTER 

The pending claims are directed to dynamically updating parameters in a configuration 
file. See, e.g., Application at 2, 1 [0001], lines 1-3. 1 The parameters in the configuration file are 
used by functional modules in a customer premises telecommunications hub. See, e.g., 
Application at 15, f [0034], line 1- Application at 16, | [0034], line 1. The functional modules 
of the customer premises telecommunications hub may include a POTS control module 51, a 
polling control module 52, a configuration update module 53, a power supply control module 83, 
an Ethernet control module 67, and an ATM control module 55, for example. See, e.g., 
Application at 9, | [0016], lines 8-15. The parameters in the configuration file may be changed 
by rebooting the hub. See, e.g., Application at 16, U [0034], lines 6-7. Because rebooting may 
require action to be taken at the location of the hub or may interrupt operation of the hub, the 
parameters are dynamically updated, if possible, without rebooting the hub. See, e.g., 
Application at 16, 1 [0034], lines 8-11. 

Upon the hub receiving and storing an updated configuration file, a process is run for 
checking whether parameters in the updated configuration file have changed, and if so whether 
they can all be changed dynamically or if a reboot is required for changing them. See, e.g., 
Application at 17, J [0036], line 3 - Application at 18, f [0038], line 5. If all of the parameters 
that have been changed can be changed dynamically, then they are updated dynamically. See, 
e.g., Application at 18, ]f [0039], lines 1-5. Otherwise, the hub is rebooted. See, e.g., 
Application at 18, f [0038], lines 5-7. It is preferred that dynamically updating the parameters or 

1 37 C.F.R. § 41.37 (c)(l)(v) provides that the "[s]ummary of claimed subject matter . . . shall 
refer to the specification by page and line number." The instant application was presented in 
numbered page and numbered paragraph form. As such, the citations to the specification support 

for the claimed subject matter will be presented in the following form: Application at (page 

number), If [ ] (paragraph number), lines (lines within the corresponding paragraph). 
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rebooting the customer premises telecommunications hub is deferred until the customer premises 
telecommunications hub is in an idle state. See, e.g., Application at 18, f [0040], line 1 - 
Application at 19, If [0041], line 6. 

An update module 53 may sequentially call a "check" function at the functional modules 
of the hub. See, e.g., Application at 17, \ [0036], lines 14-15 and Application at 18, 1 [0038], 
lines 1-7. The check function is the process of checking a new parameter against an old 
parameter and determining whether the parameter is different and if so whether it can be changed 
dynamically or requires a reboot for changing. See, e.g., Application at 17, | [0037], lines 2-7. 
Each functional module of the hub may perform the check function to determine whether any 
parameters that affect the functional module have been changed. See, e.g., Application at 17, f 
[0037], lines 2-5. For each parameter that has been changed the check function further 
determines whether the parameter can be changed dynamically or requires a reboot of the hub. 
See, e.g., Application at 17, \ [0037], line 5-8. 

If the check function determines that none of the functional parameters that have been 
changed require a reboot of the hub, then the update module 53 may call an "update" function at 
the functional modules. See, e.g., Application at 18, | [0039], lines 1-2. The update function is 
the process of storing a local copy of the new parameters and operating with the new parameters. 
See, e.g., Application at 17, If [0037], lines 2-5. Each functional module of the hub may perform 
the update function by reading the configuration parameters from the configuration file, storing a 
local copy of the new parameters, and operating with the new parameters. Id. Otherwise a 
reboot is needed to update the functional modules with the changed parameters in the 
configuration file. See, e.g., Application at 18, f [0038], lines 5-7. 

On the occasion when the pertinent paragraph is contained on multiple pages, the paragraph line 
numbering will begin anew on subsequent pages. 
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Claim 1 is independent and is directed to a method for updating configuration parameters 
in customer premises telecommunications hub comprising: receiving in a customer premises 
telecommunications hub a new configuration file sent from a remote location, See, e.g., 
Application at 17, | [0036], lines 2-10; identifying parameters in the new configuration file 
which are different than existing parameters stored in said customer premises 
telecommunications hub, See, e.g., Application at 17, f [0037], lines 2-5; checking the 
parameters which are different to determine whether they can be changed dynamically, See, e.g., 
Application at 17, | [0037], lines 5-8, and if all parameters which are different can be 
dynamically changed, updating all parameters to those contained in the new configuration file 
without rebooting, See, e.g., Application at 18, \ [0037], line 1 - Application at 18, f [0039], line 
5. 

Claim 2 depends on claim 1 and adds the limitation that if any of the parameters which 
are different cannot by dynamically changed, updating all parameters to those contained in the 
new configuration file by rebooting the system, See, e.g., Application at 17, 1 [0037], line 8- 
Application at 18, If [0037], line 1 and Application at 18, If [0038], lines 5-7. 

Claim 3 depends on claim 1 and adds the limitation that said hub comprises a 

configuration update module and a plurality of other functional modules which use parameters 

contained in the configuration file, See, e.g., Application at 9, 1 [0016], lines 8-15, Application at 

15, H [0034], line 1 - Application at 16, f [0034], line 1, and Application at 16, \ [0035], lines 9- 

11, said other functional modules register check and update function calls with said update 

module, See, e.g., Application at 16, 1 [0035], lines 2-9, said update module writes the new 

configuration file into flash memory and issues a check function call to each of the other 
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functional modules, See, e.g., Application at 17, \ [0036], lines 9-10 and lines 14-15, and each 
functional module compares configuration file parameters in the new configuration file to its 
existing parameters, and notifies the update module whether the parameters which are different 
can be changed dynamically, See, e.g., Application at 17, f [0037], lines 2-8. 

Claim 4 depends on claim 3 and adds the limitation that if the parameters which are 
different can be changed dynamically, said update module issues an update function call to each 
of the other functional modules, See, e.g., Application at 18, \ [0039], lines 1-5. 

Claim 5 depends on claim 3 and adds the limitation that if the parameters which are 
different cannot all be changed dynamically, said update module reboots the system, See, e.g., 
Application at 18, \ [0038], lines 5-7. 

Claim 6 depends on claim 1 and adds the limitation that said step of updating parameters 
is performed when said customer premises telecommunications hub is in an idle state, See, e.g., 
Application at 18, J [0040], line 1 -Application at 19, | [0040], line 2. 

Claim 7 depends on claim 1 and adds the limitation that said new configuration file is 
received over a wide area network connection in Internet protocol, See, e.g., Application at 7, f 
[0012], lines 1-6. 

Claim 8 depends on claim 1 and adds the limitation that said new configuration file is 

received over a DSL connection to a server in a central office, See, e.g., Application at 10, f 

[0020], line 1 - Application at 11, f [0020], line 4. 
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Claim 9 is independent and is directed to a customer premises telecommunications hub, 
comprising: a wide area network connection for receiving Internet protocol messages, See, e.g., 
Application at 7, | [0012], lines 1-6, a memory storing a configuration file, See, e.g., Application 
at 9, f [0016], lines 4-5 and Application at 17, 1 [0036], lines 9-10, a microprocessor having a 
plurality of functional program modules operating with parameters contained in the 
configuration file, each functional module storing configuration file parameters which affect its 
operations and having a check function and an update function, See, e.g., Application at 9, f 
[0016], lines 2-17, Application at 15, 1 [0034], lines 1-2, Application at 17, 1 [0037], lines 2-5, 
Application at 18, f [0039], lines 2-5, and Application at 16, 1 [0035], lines 2-6, and a 
configuration update module adapted to receive a new configuration file over the wide area 
network connection while the microprocessor is in a running state, to store the new configuration 
file in memory, and to call the check function and the update function in each functional module, 
See, e.g., Application at 17, | [0037], lines 4-10 and lines 14-15, Application at 14, f [0032], line 
1 1 - Application at 15, J [0032], line 1 and Application at 18, 1 [0039], lines 1-2. 

Claim 10 is independent and is directed to a system for dynamically updating 

configuration file parameters in a customer premises telecommunications hub comprising: a 

remotely located configuration server accessible over a wide area network connection, See, e.g., 

Application at 13, TJ [0026], lines 2-5, means for receiving a new configuration file from said 

configuration file server over a wide area network connection while the customer premises 

telecommunications hub is in running state, See, e.g., Application at 17, f [0036], lines 1-10, 

means for comparing parameters controlling operation of the customer premises 

telecommunications hub to parameters contained in the new configuration file and identifying 
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parameters which are different, See, e.g., Application at 17, *[f [0037], lines 4-5, means for 
identifying parameters which can be changed dynamically, See, e.g., Application at 17, If [0037], 
lines 5-7, means for, if all parameters which are different can be changed dynamically, 
dynamically updating parameters to those contained in the new configuration file, See, e.g., 
Application at 18, \ [0039], lines 1-5. 

Claim 11 depends on claim 10 and adds the limitation of a means for, if any parameter 
which is different cannot be changed dynamically, causing the customer premises 
telecommunications hub to reboot, See, e.g., Application at 18, If [0038], lines 5-7. 

Claim 12 depends on claim 10 and adds the limitation of a means for dynamically 
updating parameters to those contained in the new configuration file only when the customer 
premises telecommunications hub is in idle state, See, e.g., Application at 18, \ [0040], lines 1-4. 
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VL GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

1. Whether claims 9, 10, and 12 are anticipated under 35 U.S.C. § 102(b) by Lenz (U.S. 
Patent 6,029,196) (hereinafter Lenz). 

2. Whether claims 1, 6, and 7 are unpatentable under 35 U.S.C. § 103(a) as obvious over 
Lenz in view of Fletcher et al. (U.S. Patent 6,009,274) (hereinafter Fletcher). 

3. Whether claims 2-5 and 11 are unpatentable under 35 U.S.C. § 103(a) as obvious over 
Lenz in view of Fletcher and further in view of Sandahl et al. (U.S. Patent 6,098,098) 
(hereinafter Sandahl). 

4. Whether claim 8 is unpatentable under 35 U.S.C. § 103(a) as obvious over Lenz in view 
of Fletcher and further in view of Kaplan et al. (U.S. Patent 6,141,339) (hereinafter 
Kaplan). 



49426.02/4000.06400 



11 



Atty. Docket No. IDF 1761 (4000-06400) 
VII. ARGUMENT 

All of the claims were rejected over Lenz or Lenz in view of one or more secondary 
references. Lenz discloses an automatic client configuration system. A client may contact a 
server at startup for configuration information. The server may return the configuration file that 
is used by the client to configure the client system. Upon receiving the configuration file, the 
client executes it to configure various aspects of the client (FIGS. 1-7; column 3, lines 11-12, 23- 
24). Also, the server may query the client for information such as file version numbers. If the 
server determines that the client needs file updates, the server sends new files to the client (FIG. 
8; column 4, lines 59-64). The client may replace the existing files with the new files sent by the 
server (column 2, lines 15-17). Lenz does not disclose a customer premises telecommunication 
hub, identifying parameters within the configuration file that are different from locally stored 
parameters, or determining whether each of the changed parameters can be dynamically changed. 
None of the secondary references cure the deficiencies of Lenz. 

The Examiner has failed to establish a prima facie case of anticipation with respect to 
claim 9. "A claim is anticipated only if each and every element as set forth in the claim is found, 
either expressly or inherently described, in a single prior art reference." Verdegaal Bros. v. 
Union Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987). Lenz 
does not disclose each and every element set forth in independent claim 9. 

The Examiner has failed to establish a prima facie case of anticipation with respect to 

claims 10 and 12 because Lenz does not disclose each and every element set forth in claim 10. 

Dependent claim 12 was rejected under 35 U.S.C. § 102(b) as being anticipated by Lenz. Claim 

12 depends from claim 10 and incorporates all of the limitations thereof. Accordingly, Lenz does 

not disclose each and every element set forth in claim 12 because Lenz does not disclose each 

and every element set forth in independent claim 10. 
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The Examiner has failed to establish a prima facie case of obviousness with respect to 
claims 1-8 because Lenz in view of Fletcher does not teach or suggest all of the elements of 
independent claim 1 . As noted by the United States Supreme Court in Graham v. John Deere 
Co. of Kansas City, an obviousness determination begins with a finding that "the prior art as a 
whole in one form or another contains all" of the elements of the claimed invention . See 
Graham v. John Deere Co. of Kansas City, 383 U.S. 1, 22 (U.S. 1966). Dependent claims 6 and 
7 were rejected under 35 U.S.C. § 103(a) as obvious over Lenz in view of Fletcher. Dependent 
claims 2-5 were rejected under 35 U.S.C. § 103(a) as obvious over Lenz in view of Fletcher and 
further in view of Sandahl. Dependent claim 8 was rejected under 35 U.S.C. § 103(a) as obvious 
over Lenz in view of Fletcher and further in view of Kaplan. Dependent claims 2-8 depend 
directly or indirectly from independent claim 1 and incorporate all of the limitations thereof. 
Accordingly, none of the combinations of applied art teach or suggest all of the claim elements 
set forth in dependent claims 2-8 because Lenz in view of Fletcher does not teach or suggest all 
of the claim elements set forth in independent claim 1 . 

The Examiner has failed to establish a prima facie case of obviousness with respect to 
dependent claim 11. Dependent claim 1 1 was rejected under 35 U.S.C. § 103(a) as obvious over 
Lenz in view of Fletcher and further in view of Sandahl. Dependent claim 1 1 depends directly 
or indirectly from independent claim 10 and incorporates all of the limitations thereof. 
Accordingly, Lenz in view of Fletcher and in further view of Sandahl does not teach or suggest 
all of the claim elements set forth in dependent claim 1 1 because Lenz does not disclose each and 
every element set forth in independent claim 10. 

A. 35 U.S.C. § 102 Rejections 
1. Claim 9 

13 
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a. Claim 9 was wrongly rejected because Lenz does not 
disclose a customer premises telecommunications hub 

In the response filed on April 24, 2007, Appellants argued that the client of Lenz is not a 
customer premises telecommunications hub. The Final Office Action responded to this 
argument in section (A) of the Response to Arguments section. In section (A), the Final Office 
Action appears to interpret the disclosure of Lenz that because there is communication between 
the client and the server then the presence of a communications hub is inherent to the client. 
The Advisory Action dated September 20, 2007 simply repeats the argument found in section 
(A) of the Final Office Action. While some sort of communications means, such as an RJ-1 1 
(telephone) jack or an Ethernet port, may be inherent to the client of Lenz, Appellants submit 
that the presence of a communications hub is not inherent to the client of Lenz. Further, Lenz 
does not disclose that the communication means between the client and the server is disclosed to 
have the other limitations of Claim 9. For example, Lenz does not disclose that the means for 
communicating between the client and the server has a wide area network connection, a 
memory, a microprocessor, and a configuration update module as claimed. 

In a telephone interview on October 23, 2007 Appellants presented arguments that the 
claimed customer premises telecommunications hub is not inherent in the client of Lenz. The 
Examiner responded to those arguments by indicating that even if the claimed customer 
premises telecommunications hub is not inherent to the client of Lenz, based on the definition of 
the term "hub," the server may be broadly interpreted as a customer premises 
telecommunications hub. Appellants respectfully submit that the server of Lenz does not 
disclose the other limitations of claim 9. For example, the server of Lenz is not disclosed to 
have the claimed plurality of functional program modules, each storing configuration file 
parameters which affect its operations and having a check function and an update function. 

14 
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Further, the server of Lenz is not disclosed to have a configuration update module adapted to 

call the check function and the update function in each functional module. 

Appellants note that Lenz does not directly disclose that the client is a customer premises 

telecommunications hub. MPEP 706.02(IV) indicates that for rejections under 35 U.S.C. 102, 

"Any feature not directly taught must be inherently present." Further, MPEP 2163.07(a) notes, 

"To establish inherency, the extrinsic evidence 'must make clear that the missing descriptive 

matter is necessarily present in the thing described in the reference, and that it would be so 

recognized by persons of ordinary skill. Inherency, however, may not be established by 

probabilities or possibilities. The mere fact that a certain thing may result from a given set of 

circumstances is not sufficient." In re Robertson, 169 F.3d 743, 745, 49 USPQ2d 1949, 1950- 

51 (Fed. Cir. 1999) (citations omitted) (emphasis added). In other words, unstated elements in a 

reference are inherent when they exist as a "matter of scientific fact." Constant v. Advanced 

Micro Devices, Inc., 848 F.2d 1560, 7 U.S.P.Q.2d 1057 (Fed. Cir.), cert, denied, 488 U.S. 892 

(1988) and Hughes Aircraft Co. v. United States, 8 U.S.P.Q.2d 1580 (Ct. CI. 1988). 

Also, MPEP 2173.05(a)(III) states: 

"In applying the prior art, the claims should be construed to encompass all 
definitions that are consistent with Appellant's use of the term. See Tex. Digital 
Sys., Inc. v. Telegenix, Inc., 308 F.3d 1193, 1202, 64 USPQ2d 1812, 1818 (Fed. 
Cir. 2002). It is appropriate to compare the meaning of terms given in technical 
dictionaries in order to ascertain the accepted meaning of a term in the art. In re 
Barr, 444 F.2d 588, 170 USPQ 330 (CCPA 1971). >See also MPEP § 2111.01.<" 

The Federal Standard 1037C Glossary of Telecommunications Terms defines the term 

"hub" as "a device that accepts a signal from one point and redistributes it to one or more points." 

Also, the website Whatis.com provides a common definition of the term "hub" as "a place of 

convergence where data arrives from one or more directions and is forwarded out in one or more 

other directions." While the client of Lenz is disclosed to receive data from the server, Lenz does 
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not provide any disclosure that the client then redistributes or forwards the data on to one or 
more points or in one or more directions. Appellants note that while the client of Lenz is also 
disclosed to be able to send data to the server, this is not disclosure of redistributing or 
forwarding data that has arrived at the client to the server. For example, the server may send 
data to the client, the client may process the data and respond or initiate a request with different 
data, however, the client of Lenz does not redistribute or forward the same data back to the 
server. Therefore it is clear that the client of Lenz is not a "hub," much less a customer premises 
telecommunications hub as claimed. Further, Appellants respectfully submit that a hub is not 
necessarily present in Lenz, nor is it a matter of scientific fact that the client of Lenz is a hub. For 
additional clarity, Appellants note that a term that is commonly used today that may describe the 
customer premises telecommunications hub is "residential gateway." 

Further, regarding the claim limitation "customer premises," Appellants note that Lenz 
does not directly disclose that the client is a customer premises client. A search of Lenz did not 
result in any disclosure of a customer premises. Appellants respectfully submit that it is not 
necessarily present or a matter of scientific fact that the client of Lenz is a customer premises 
client. 

b. Claim 9 was wrongly rejected because Lenz does not 
disclose a plurality of functional program modules 
operating with parameters contained in the 
configuration file. 

Claim 9 recites, "a customer premises telecommunications hub, comprising ... a 
microprocessor having a plurality of functional program modules operating with parameters 
contained in the configuration file, each functional program module storing configuration file 
parameters which affect its operations." As described in paragraph 0016 of the pending 
disclosure, the functional program modules may include a control module 51 that controls the 
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telephony functions, an Ethernet control module 67, and ATM control module 55 that controls 
the communications with the network, for example. 

The Final Office Action relied on Fig. 4 of Lenz to teach the cited limitations claimed in 
claim 9. Appellants respectfully submit that the cited portions of Lenz do not disclose that the 
client 401 has a plurality of functional program modules. In the Response to the Final Office 
Action dated August 31, 2007, Appellants requested that particular structures of Fig. 4 or 
citations of descriptions of Fig. 4 that are being interpreted as the claimed plurality of functional 
program modules be particularly pointed out. The Advisory Action dated September 20, 2007 
did not provide any such identification of particular structures or descriptions of Lenz. 
Appellants respectfully submit that Lenz does not disclose a configuration file stored at the 
client 401 where a plurality of functional program modules operate with parameters contained in 
the configuration file. Still further, Appellants respectfully submit that Lenz does not disclose 
that each of the functional program modules store parameters of the configuration file that affect 
their operations. 

c. Claim 9 was wrongly rejected because Lenz does not 
disclose a check function. 

Claim 9 recites, "a plurality of functional program modules each functional module ... 
having a check function" and, "a configuration update module adapted ... to call the check 
function ... in each functional module." Paragraph 0037 of the pending application discloses that 
the check function determines whether any parameters which affect a functional module have 
been changed and, for each parameter that has been changed, the check function further 
determines whether the parameter can be changed dynamically or requires a reboot of the hub. 

The Final Office Action relied on Fig. 4 and Fig. 12 of Lenz to teach the limitations 
claimed in claim 9. As discussed in column 3, lines 40-55, Fig. 4 of Lenz discloses an 
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embodiment where a client 401 may request remotely stored configuration settings through 
LDAP commands on the JSC file 403. The request may include a user's E-mail address that may 
be passed to the LDAP server 405 as a key to request a given user's settings. Information 
returned from the LDAP server 405 may include other settings, such as the user's mail server 
name. This embodiment is a more specific example of the other embodiments of Lenz that 
disclose for a client to request configuration information from a server, the server returns the 
configuration information corresponding to the requesting client, and the client executes the 
returned configuration information to configure various aspects of the client. 

Fig. 12 of Lenz and column 5, line 62- column 6, line 10 describes the functionality of the 
server. The process in column 5, line 62 - column 6, line 3 describes the functions performed on 
the server to retrieve the appropriate configuration information based on a client request for 
configuration information and to send the retrieved configuration information to the client. 
Appellants respectfully submit that disclosure of functionality provided by the server of Lenz 
does not provide any disclosure of the limitations of the customer premises telecommunications 
hub claimed in Claim 9. 

Appellants respectfully submit that the cited portions of Lenz do not disclose any 
function to determine whether any parameters within a configuration file have changed. Lenz 
simply executes the returned configuration information without any check of whether there are 
changes in individual parameters of the returned configuration information. Further, since there 
isn't any disclosure of checking whether individual parameters of the configuration information 
have changed then there is also no disclosure of determining whether parameters that have been 
changed require a reboot. 
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d. Claim 9 was wrongly rejected because Lenz does not 
disclose an update function. 

Claim 9 recites, "a plurality of functional program modules each functional module ... 
having an update function" and, "a configuration update module adapted ... to call the ... update 
function in each functional module." Paragraph 0039 of the pending application discloses that 
the update function reads configuration parameters from the new configuration file which affect 
the functional module and stores a local copy of the new parameters. The updated functional 
module operates with the new parameters. 

The Final Office Action again relied on Fig. 4 and Fig. 12 of Lenz to teach the 
limitations claimed in claim 9. Appellants respectfully submit that Figs. 4 and 12 and their 
corresponding description in Lenz do not disclose any function to copy parameters from the 
returned configuration information that affect a functional module and store a copy of the new 
parameters local to the functional module such that the functional module operates with the new 
parameters. 

e. Claim 9 was wrongly rejected because Lenz does not 
disclose a configuration update module. 

Claim 9 recites, "a customer premises telecommunications hub, comprising ... a 
configuration update module adapted to receive a new configuration file ... and to call the check 
function and the update function in each functional module." 

The Final Office Action relied on the disclosure of Fig. 12 of Lenz to read on the cited 

claim limitations of claim 9. As noted above, Fig. 12 shows the processes that may be performed 

by the server. In contrast, the limitations of the configuration update module are recited as part of 

the claimed customer premises telecommunications hub, which the Final Office Action has 

interpreted as the client in the disclosure of Lenz. It is unclear how processes performed on the 

server may be interpreted as functionality of the client. 
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Appellants respectfully submit that Fig. 12 and the corresponding description in Lenz do 

not disclose that the server calls the check function and the update function as claimed. Further, 

none of the processes of Fig. 12 call any functions to "each functional module" as claimed. 

Appellants respectfully submit that the client of Lenz described in conjunction with Fig. 4 also 

does not provide any disclosure of the claimed configuration update module. 

f. Claim 9 was wrongly rejected because Lenz does not 
disclose each and ever limitation of claim 9. 

For at least the reasons established above in sections (A)(l)(a)-(A)(l)(e), Appellants 

respectfully submit that independent Claim 9 is not disclosed by Lenz and respectfully request 

allowance of this claim. 

2. Claims 10 and 12 

a. Claim 10 was wrongly rejected because Lenz does not disclose 
a customer premises telecommunications hub. 

Appellants respectfully submit that Lenz does not disclose a customer premises 

telecommunications hub. Appellants refer to the argument in section (A)(1)(a) above. For 

brevity the argument is not repeated here. 

b. Claim 10 was wrongly rejected because Lenz does not 
disclose comparing parameters of the hub to 
parameters in the new configuration file and identifying 
which parameters are different. 

Claim 10 recites, "comparing parameters controlling operation of the customer premises 
telecommunications hub to parameters contained in the new configuration file and identifying 
parameters which are different." 

In the response filed on April 27, 2007, Appellants argued that Lenz does not teach or 
suggest any step of identifying parameters in a new configuration file that are different from 
existing parameters stored in a customer premises telecommunications hub. The Final Office 
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Action responded to this argument in section (B) of the Response to Arguments section. In 
section (B), the Final Office Action relied on disclosure of the limitations of Claim 1 in Column 
6, lines 28-35 of Lenz. The Final Office Action summarizes the process of Claim 1 of Lenz as 
updating the old files with the new files. The Final Office Action interprets the updating as 
inherently identifying parameters in a new file that are different from existing parameters. The 
Advisory Action dated September 20, 2007 simply repeats the argument found in section (B) of 
the Final Office Action. 

Appellants note that Lenz does not directly disclose that parameters of the configuration 
file received from the server are compared with parameters controlling operation of the client 
and identifying parameters which are different. Lenz only discloses in column 3, lines 11-12 
that the configuration file is executed upon receipt. 

Appellants respectfully submit that performing a comparison of parameters in the 

configuration file received from the server with parameters controlling operation of the client 

and identifying parameters which are different is not necessarily present in Lenz. Further, it is 

not a matter of scientific fact that configuring the client using the configuration file received 

from the server has to perform a comparison of parameters in the configuration file received 

from the server with parameters controlling operation of the client and identifying parameters 

which are different. For example, as alluded to in the interpretation provided in the argument of 

section (B) of the Final Office Action, the configuration file may simply overwrite or swap out 

the old files with the new files to perform an update without ever performing a comparison or 

identification of differences as claimed in Claim 10. 

c. Claim 10 was wrongly rejected because Lenz does not 
disclose identifying parameters which can be changed 
dynamically. 

Claim 10 recites, "identifying parameters which can be changed dynamically." 
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In the response filed on April 27, 2007, Appellants argued that Lenz does not teach or 
suggest making any determination of whether parameters may be changed dynamically. The 
Final Office Action responded to this argument in section (C) of the Response to Arguments 
section. In section (C), the Final Office Action relied on disclosure in Column 4, lines 28-42 of 
Lenz. The Final Office Action likens the disclosure of an administrator automatically pushing 
out software updates that he wants to a determination of whether parameters may be changed 
dynamically. The Advisory Action dated September 20, 2007 simply repeats the argument 
found in section (C) of the Final Office Action. Appellants respectfully submit that the 
disclosure cited in section (C) of the Final Office Action merely teaches that an administrator 
can identify what software to update. Lenz does not teach or suggest identifying parameters 
which can be changed dynamically as required by Claim 10. 

The rejection of Claim 10 in the Final Office Action relied on disclosure of column 6, 
lines 28-29. This disclosure is merely a limitation of Claim 1 of an operation performed on the 
server. The server identifies a configuration file that is associated with the client. Appellants 
note that this is an identification of a file, not an identification of parameters within a file. 
Further, there is no teaching or suggestion of identifying parameters which can be changed 
dynamically. 

As disclosed in paragraph 0037 of the pending application, each parameter used in a 
module is designated as to whether or not it can be dynamically changed or requires a system 
reboot. Therefore, some parameters can be dynamically changed and other parameters can not 
be dynamically changed and require a system reboot. Lenz does not provide any such disclosure 
of some parameters being able to be dynamically changed and others not being able to be 
dynamically changed. Therefore, Lenz does not provide any disclosure of identifying 
parameters which can be dynamically changed. 
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d. Claim 10 was wrongly rejected because Lenz does not 
disclose dynamically updating parameters if all 
parameters which are different can be dynamically 
changed. 

In the Final Office Action dated July 13, 2007, the Examiner asserts that Lenz teaches 
means for, if all parameters which are different can be changed dynamically, dynamically 
updating parameters to those contained in the new configuration file, citing col. 5, lines 41-44. 

As noted above in section 2(c), Lenz teaches nothing about distinguishing between 
parameters which can be changed dynamically and those that can be changed only by rebooting. 
Accordingly, Lenz could not teach a step of updating based on such distinction. The cited 
portion of Lenz discusses only the transfer of parameters from the server to the client. It has 
nothing to do with how the client changes the parameters internally. 

While Lenz provides a number of teachings concerning transferring parameters and files 
between a server and a client, Lenz does not provide any teachings about how the new 
parameters or files are actually installed or implemented in the client. 

e. Claim 10 was wrongly rejected because Lenz does not 
disclose conditionally performing a dynamic update of 
parameters. 

Claim 10 recites, "if all parameters which are different can be changed dynamically, 
dynamically updating parameters to those contained in the new configuration file." Therefore, 
Claim 10 requires that the condition be met that all of the parameters that have been identified 
as different have also been identified as parameters which can be changed dynamically prior to 
dynamically updating the parameters. 

A search of Lenz for the term "dynamic" in the detailed description only resulted in 
discussion related to Fig. 3 in column 3, lines 26-39 and discussion related to Fig. 4 in column 
3, lines 40-48. In column 3, lines 40-48, Lenz discloses that the JSC file is more flexible with 
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the addition of LDAP commands that allow set configuration data to be dynamically set rather 
than statically set. Appellants note that there is no disclosure of any conditions being met prior 
to dynamically setting configuration data, much less disclosure of a condition that all of the 
parameters that have been identified as different have also been identified as parameters which 
can be changed dynamically prior to dynamically updating the parameters. 

The condition required by Claim 10 is further emphasized through the limitations of 
Claim 11, where the other side of this condition is defined as "if any parameter which is different 
cannot be changed dynamically, causing the customer premises telecommunications hub to 
reboot." 

f. Claims 10 and 12 were wrongly rejected because Lenz 
does not disclose each and every limitation of claim 10. 

For at least the reasons established above in sections (A)(2)(a)-(A)(2)(e), Appellants 
respectfully submit that independent Claim 10 is not disclosed by Lenz and respectfully request 
allowance of this claim. 

Dependent Claim 12 depends directly or indirectly from independent Claim 10 and 
incorporates all of the limitations thereof. Accordingly, for at least the reasons established in 
sections (A)(2)(a)-(A)(2)(e) above, Appellants respectfully submit that Claim 12 is not disclosed 
by Lenz and respectfully request allowance of this claim. 

B. 35 U.S.C. § 103(a) Rejections 

1. Claims 1-8. 

a. Claim 1 was wrongly rejected for the reasons discussed 
above. 

Claim 1 includes limitations substantially similar to the limitations discussed in sections 

(A)(1)(a) and (A)(2)(a)-(A)(2)(e) above. Appellants refer to the arguments in sections (A)(1)(a) 

and (A)(2)(a)-(A)(2)(e) above. For brevity these arguments are not repeated here. 
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b. The secondary references do not cure the deficiencies of 
Lenz. 

The Final Office Action dated July 13, 2007 relied on Fletcher to provide disclosure of 
installing a new version of a software component without rebooting system software. Appellants 
respectfully submit that this disclosure does not cure the deficiencies of Lenz detailed in the 
arguments of sections (A)(1)(a) and (A)(2)(a)-(A)(2)(e). Further, the Final Office Action dated 
July 13, 2007 relied on Sandahl and Kaplan to teach limitations of dependent claims. Appellants 
respectfully submit that neither Sandahl nor Kaplan cure the deficiencies of Lenz detailed in the 
arguments of sections (A)(1)(a) and (A)(2)(a)-(A)(2)(e). 

c. Claims 1-8 were wrongly rejected because Lenz in view 
of Fletcher does not teach or suggest all of the claim 
elements of claim 1. 

For at least the reasons established above in sections (A)(1)(a) and (A)(2)(a)-(A)(2)(e), 
Appellants respectfully submit that independent Claim 1 is not taught or suggested by Lenz in 
view of Fletcher and respectfully request allowance of this claim. 

Dependent Claims 2-8 depends directly or indirectly from independent Claim 1 and 
incorporate all of the limitations thereof. Accordingly, for at least the reasons established in 
sections (A)(1)(a) and (A)(2)(a)-(A)(2)(e) above, Appellants respectfully submit that Claims 2-8 
are not taught or suggested by Lenz in view of Fletcher and respectfully request allowance of this 
claim. 

2. Claim 11 

a. Claim 11 was wrongly rejected because Lenz does not 
disclose each and every limitation of claim 10. 

Dependent Claim 11 depends directly or indirectly from independent Claim 10 and 

incorporates all of the limitations thereof. Accordingly, for at least the reasons established in 

sections (A)(2)(a)-(A)(2)(e) above, Appellants respectfully submit that Claim 1 1 is not taught or 
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suggested by Lenz in view of Fletcher in further view of Sandahl and respectfully request 
allowance of this claim. 



In view of the above arguments the Appellants respectfully request that the Final 
Rejection of the claims be reversed and the case advanced to issue. Should the Examiner feel 
that a telephone interview would advance prosecution of the present application, the Appellants 
invite the Examiner to call the attorneys of record. 

The Commissioner is hereby authorized to charge payment of any further fees associated 
with any of the foregoing papers submitted herewith, or to credit any overpayment thereof, to 
Deposit Account No. 21-0765, of Sprint Communications Company, L.P. 



CONCLUSION 



Respectfully submitted, 
CONLEYROSE, P.C. 



Date: 




Conley Rose, P.C. 

5601 Granite Parkway, Suite 750 

Piano, Texas 75024 

(972) 731-2288 

(972)731-2289 (facsimile) 
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VIII. CLAIMS APPENDIX 

1. A method for updating configuration parameters in customer premises 
telecommunications hub comprising: 

receiving in a customer premises telecommunications hub a new configuration file sent 
from a remote location; 

identifying parameters in the new configuration file which are different than existing 
parameters stored in said customer premises telecommunications hub; 

checking the parameters which are different to determine whether they can be changed 
dynamically, and 

if all parameters which are different can be dynamically changed, updating all parameters 
to those contained in the new configuration file without rebooting. 

2. A method according to Claim 1, further comprising: 

if any of the parameters which are different cannot by dynamically changed, updating all 
parameters to those contained in the new configuration file by rebooting the system. 
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3 . A method according to Claim 1 , wherein: 

said hub comprises a configuration update module and a plurality of other functional 
modules which use parameters contained in the configuration file, 

said other functional modules register check and update function calls with said update 
module, 

said update module writes the new configuration file into flash memory and issues a 
check function call to each of the other functional modules, and 

each functional module compares configuration file parameters in the new configuration 
file to its existing parameters, and notifies the update module whether the parameters which are 
different can be changed dynamically. 

4. A method according to Claim 3, wherein: 

if the parameters which are different can be changed dynamically, said update module 
issues an update function call to each of the other functional modules. 

5. A method according to Claim 3, wherein: 

if the parameters which are different cannot all be changed dynamically, said update 
module reboots the system. 

6. A method according to Claim 1 , wherein: 

said step of updating parameters is performed when said customer premises 
telecommunications hub is in an idle state. 
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7. A method according to Claim 1, wherein: 

said new configuration file is received over a wide area network connection in Internet 
protocol. 

8. A method according to Claim 1, wherein: 

said new configuration file is received over a DSL connection to a server in a central 

office. 

9. A customer premises telecommunications hub, comprising: 

a wide area network connection for receiving Internet protocol messages, 
a memory storing a configuration file, 

a microprocessor having a plurality of functional program modules operating with 
parameters contained in the configuration file, each functional module storing configuration file 
parameters which affect its operations and having a check function and an update function, and 

a configuration update module adapted to receive a new configuration file over the wide 
area network connection while the microprocessor is in a running state, to store the new 
configuration file in memory, and to call the check function and the update function in each 
functional module. 
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10. A system for dynamically updating configuration file parameters in a customer premises 
telecommunications hub comprising: 

a remotely located configuration server accessible over a wide area network connection, 
means for receiving a new configuration file from said configuration file server over a 

wide area network connection while the customer premises telecommunications hub is in 

running state, 

means for comparing parameters controlling operation of the customer premises 
telecommunications hub to parameters contained in the new configuration file and identifying 
parameters which are different, 

means for identifying parameters which can be changed dynamically, 
means for, if all parameters which are different can be changed dynamically, dynamically 
updating parameters to those contained in the new configuration file. 

1 1 . The system of Claim 1 0 further comprising: 

means for, if any parameter which is different cannot be changed dynamically, causing 
the customer premises telecommunications hub to reboot. 

12. The system of Claim 10 further comprising: 

means for dynamically updating parameters to those contained in the new configuration 
file only when the customer premises telecommunications hub is in idle state. 
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IX. EVIDENCE APPENDIX 
None. 
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X. RELATED PROCEEDINGS APPENDIX 
None 
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